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Scope  of  the  Document 

In  response  to  a Goddard  Space  Flight  Center  effort  to  look  at  the  requirements  for  a computing 
architecture  design  appropriate  for  a telerobot,  this  document  describes  the  Intelligent  Controls 
Group  approach  to  telerobot  computing  architectures.  It  is  shown  how  a seven  microprocessor  con- 
trol system  can  achieve  teleoperation  with  an  around- the-loop  time  of  10  ms.  The  document  focus- 
es on  low-level,  real-time  robotics  and  does  not  discuss  some  issues  relevant  to  space  systems  such 
as  space-qualification  and  thermal  design. 
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1.  Introduction 

This  document  presents  a basic  design  for  a telerobot.  The  complete  robot  design  is  not  pre- 
sented here,  however,  detailed  designs  of  principal  subsystems  are  presented.  The  emphasis  is  on 
the  approaches  taken  toward  softw-are  and  hardware  design  of  the  computing  architecture.  Example 
designs  are  taken  from  the  Servo  Level.  The  motivation  for  the  control  system  design  is  completely 
documented  in  the  references  at  the  end.  The  bibliography  is  a complete  list  of  publications  from 
the  Robot  Systems  Division,  National  Institute  of  Standards  and  Technology  (NIST),  related  to  the 
design  of  telerobot  control  systems. 

2.  Software 

To  facilitate  the  discussion  and  simplify  the  figures,  the  following  discussion  on  the  design  of 
software  will  concentrate  on  the  Servo  Levels  of  two  main  subsystem's  of  the  telerobot,  the  hand- 
controller  subsystem  of  the  operator  interface  and  the  manipulator  subsystem  of  the  robot  side. 
These  two  subsystems  are  the  main  emphasis  for  projects  such  as  Martin  Marietta’s  FTS  and  God- 
dard’s Multiple  Algorithm  Robot  Control  System  (MARCS).  Other  levels  and  subsystems  will 
have  similar  structure,  so  the  example  can  be  applied  to  other  parts  of  the  system  as  well. 

The  control  system  forms  two  main  hierarchies,  one  for  the  operator  interface  and  one  for  the 
robot.  In  the  operator  interface  hierarchy,  a hand-controller  subsystem  consists  of  a Primitive  and 
Servo  Level  under  the  E-move  Level.  Likewise,  as  shown  in  Figure  1,  a manipulator  controller 


Figure  1.  Subsystem  Design  for  Arm  and  Hand  Controller  of  Telerobot. 
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consists  of  a Primitive  and  Servo  Level  under  the  Manipulation  E-move  Level.  On  the  robot  side 
there  are  also  E-move  Levels  for  the  Perception  and  Positioning  subsystems.  There  is  a second  ma- 
nipulator subsystem  under  the  Manipulation  E-move  Level.  This  subsystem  controls  the  second 
manipulator  arm  in  a two  arm  telerobot.  Similarly,  there  is  a second  hand-controller  subsystem  in 
the  operator  interface.  In  the  discussion,  the  control  subsystem  for  only  one  manipulator/hand-con- 
troller pair  will  be  presented,  the  assumption  being  that  a second  manipulator/hand-controller  pair 
would  have  a duplicate  control  structure. 

The  Servo  Levels  depicted  in  Figure  1 are  directed  by  the  corresponding  Primitive  Levels. 
However,  in  teleoperation  mode,  the  two  Servo  Levels  are  linked  through  the  global  data  system. 
The  manipulator  is  moved  based  on  sensory  data  generated  in  the  hand-controller  subsystem  and 
the  hand-controller  is  activated  by  sensory  data  generated  in  the  manipulator  subsystem.  This  tele- 
operation mode  will  be  the  focus  of  the  discussion. 

Figure  2 shows  a detailed  design  for  the  Servo  Levels  of  Figure  1 . Figure  2. a represents  the  ma- 
nipulator subsystem  Servo  Level  and  Figure  2.b  represents  the  hand-controller  Servo  Level.  Each 
box  in  Figure  2 is  a cyclicly-executing,  concurrent  software  process  of  the  control  system.  The 
ovals  are  global  data  buffers.  System  processes  communicate  only  through  these  global  buffers. 
The  particular  configuration  of  boxes  shown  in  Figure  2 is  primarily  based  on  the  control  archi- 
tecture of  the  NIST  lab  system,  but  includes  elements  for  the  implementation  of  Martin  Marietta’s 
control  algortihm.  This  design  is  also  similar  to  the  MARCS  system,  which  is  specifically  designed 
to  support  algorithms  like  Martin’s.  (See  Appendix  1 for  the  detailed  MARCS  design.)  Additional 
boxes  might  be  added  for  other  algorithms,  such  as  the  Goddard  teleoperation  algorithm  with  adap- 
tive gains,  however  the  basic  arrangement  and  characteristic  of  software  processes  depicted  in  Fig- 
ure 2 is  designed  to  support  a wide  range  of  algorithms  without  major  modification. 

Note  that  not  all  possible  inputs  and  outputs  of  processes  are  shown  in  the  figure.  The  figure 
shows  all  inputs  and  outputs  necessary  for  the  basic  teleoperation  mode  under  consideration.  De- 
tailed descriptions  of  the  inputs  and  outputs  to  the  processes  in  Figure  2 can  be  found  in  the  refer- 
ences. Interfaces  shown  are  assumed  to  be  complete  interfaces  as  described  in  the  documents  even 
though  only  a subset  of  a given  interface  might  be  used  for  the  algorithm  being  discussed.  Also, 
the  output  from  the  Servo  Level  is  the  desired  torque  for  the  joints.  It  is  assumed  that  either  this 
value  is  directly  proportional  to  the  required  motor  current,  as  in  the  direct-drive  case,  or  that  torque 
loops  are  provided  subsequent  to  the  output. 

The  data  buffers  used  for  communication  between  subsystems  are  shown  shaded  in  Figure  2. 
The  two  buffers  are  repeated  in  both  figures  for  clarity.  The  buffer  f^^  contains  the  force  feedback 
from  the  robot  force  sensor  related  to  the  Cartesian  coordinates  of  the  hand-controller.  The  buffer 
Zq  contains  the  Cartesian  hand-controller  command  related  to  the  Cartesian  coordinates  used  for 
the  robot  control.  The  Zq  data  is  the  final  hand-controller  command  which  includes  indexing  and 
scaling. 

Each  process  at  the  Servo  Level  in  Figure  2 has  associated  with  it  a number  appearing  in  the 
upper  right-hand  comer  of  the  box.  Table  1 gives  the  execution  times  for  each  process  executing 
the  appropriate  component  of  the  Martin  Marietta  algorithm.  Note  that  the  Martin  algorithm  is 
completely  implemented  by  the  numbered  processes.  In  fact,  some  additional  functionality  (such 
as  gravity  compensation)  is  provided  which  is  not  available  in  Martin’s  implementation.  The  exe- 
cution times  are  based  on  Martin  Marietta  published  data.  Martin  Marietta  obtained  these  times  by 


Approach  to  Computing  Arch. 


3 


5 


A 

U 


0 

c 

0 

0 

c 

t— ' 

c 

0 

c/5 

c/5 

0 

00 

< 

x> 

0 

A 


W 


— 

\ 

Q bfl 

H £ 

£ 

CO  Co 

(N 

Q 

c 

H 

0 

0 

3 

0 

0 

0 

X 

00 

W 

V2 

<_,  (U 
^ c 3 

O C. 

"->0 


- 

04 

u 

fO 

4-> 

c 

8 

•H 

(U 

Cu 

0 

<u 

CO 

lu 

<N 

cr 

EH 

4-) 

(U 

(0 

u 

•H 

0 

Q- 

M 

0 

CO 

s 

bj 

b« 

oj  o 

052 
u-  c 
O o 

<*-.  c/3 


4 


Figure  2.  a.  Manipulator  Subsystem  Detailed  Design. 


oc 
C O 
O C 


c/5 

•4— » ^ 

c 3 

o 


5 


Figure  2.  b.  Hand  Controller  Subsystem  Detailed  Design. 


Table  1.  Execution/Communication  Times  for  Figure  2 Processes  in  Martin  Algorithm. 


Process 

Process  Function  in  Martin  Algortihm 

Execution  Time  (msec) 

1 

Acquire  joint  feedback 

0.34 

2 

Acquire  force/torque  sensor  data 

0.17 

3 

Calc,  position  mod.  based  on  impedance 

1.50 

4 

N/A 

2.10 

5 

Calc,  inertia  decoupling  matrix 

17.00 

6 

N/A 

4.70 

7 

Forward  kinematics  on  joint  position 

1.43 

8 

Trans,  force  sensor  data  to  control  coord. 

0.38 

9 

Translate  manip.  to  hand  cntllr  coord. 

0.39 

10 

Combine  imp.  and  cmd/  inverse  kinematics 

1.47 

11 

Joint  rate  limiting 

0.27 

12 

Joint  PD  control  with  inertia  decoupling 

0.90 

13 

N/A 

0.25 

14 

Force  feedback  limiting 

0.27 

15 

Jacobian  transpose  multiplication 

0.57 

16 

Translate  hand  cntrllr  to  manip.  coord. 

0.78 

17 

N/A 

1.80 

18 

Calc,  hand-controller  Jacobian 

1.32 

19 

Forward  kinematics  on  joint  position 

1.43 

20 

Acquire  joint  feedback 

0.34 

implementing  and  timing  actual  Ada  code  on  the  80386  microprocessor.  In  calculating  the  times 
for  Table  1 for  each  process,  Martin  Marietta  execution  times  for  functions  performed  in  a process 
were  summed  and  the  resulting  value  was  multiplied  by  1.2  to  allow  for  a communication  overhead 
of  20%.  The  result  is  rounded  up  to  the  nearest  hundredth  of  a millisecond.  For  processes  for  which 
execution  times  are  not  available,  times  obtained  on  Ada  code  implemented  on  the  68020  for  a sev- 
en degree-of-freedom  manipulator  control  system  were  used  as  comparable  values.  The  execution 
times  of  Table  1 are  used  in  the  next  section  to  show  how  processes  can  be  distributed  to  processors 
for  real-time  performance  when  the  correct  hardware  architecture  is  chosen. 

3.  Hardware 

The  problem  of  telerobot  control  requires  a powerful  multiprocessing  architecture.  This  multi- 
processing architecture  must  involve  a large  number  of  tightly-coupled  processors  to  perform  the 
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highly  centralized  aspects  of  coordinated  control.  This  fact  will  be  demonstrated  for  the  example 
subsystems  of  Section  2.  First,  consider  the  following  desirable  features  of  the  centralized  part  of 
the  computer  architecture  design  for  a telerobot. 

3.1.  Processor  coupling  via  a 32-bit  data  bus. 

The  rate  that  data  is  transferred  between  processors  in  the  control  system  requires  that  the  com- 
munication bus  support  a high  communication  bandwidth.  Since  many  processors  will  share 
the  same  data  bus,  megaword-per-second  data  rates  are  necessary.  Also,  the  word  size  for  val- 
ues used  in  robot  applications  is  mostly  32  bits,  since  robot  control  computations  are  done  using 
32-bit  floating  point  representations.  Current  floating  point  hardware  technology  is  capable  of 
computations  with  no  less  than  32  bits.  Any  smaller  representation  requires  expensive  conver- 
sions to  a larger  format.  In  addition,  32-bit  data  is  the  state-of-the-art  in  microprocessors  and 
multi-microprocessor  backplanes. 

3.2.  Multislot  (>20)  backplane. 

To  accommodate  the  large  number  of  processors  and  allow  for  easy  system  expansion,  a mul- 
tislot backplane  is  required.  Processor  and  other  hardware  elements  connected  by  an  address 
and  data  bus  configured  as  a multislot  backplane  provides  for  tight  coupling  with  the  added 
benefit  that  elements  can  easily  be  added  or  removed.  Even  a 20-slot  backplane  may  not  be  big 
enough  depending  on  the  complexity  of  the  system  and  its  degree  of  autonomy.  Multiple  mul- 
tislot backplanes  may  be  desirable. 

3.3.  Subsystem  bus  capability. 

In  addition  to  a high-bandwidth  main  bus  connecting  processors,  it  is  useful  to  have  subsystems 
buses  that  allow  subgroups  of  processors  to  communicate  separately  from  the  main  bus.  For 
example,  the  processors  performing  centralized  control  of  an  arm  need  to  communicate  more 
frequently  with  each  other  than  they  do  with  the  processors  controlling  the  other  arm,  in  gen- 
eral. This  communication  is  local  to  the  arm  processors  and  traffic  on  the  main  bus  can  be  re- 
duced by  giving  the  arm  processors  a separate  subsystem  bus.  The  arm  processors  can  still  use 
the  main  bus,  but  use  the  subsystem  bus  for  communication  within  the  subsystem.  Since  the 
values  transferred  over  the  subsystem  bus  are  for  the  most  part  32-bit,  the  subsystem  bus  should 
also  have  a 32-bit  data  path. 

3.4.  Industry  standards. 

Any  computer  architecture  design  should  try  to  use  industry  standards  where  possible.  Com- 
pliance to  industry  standards  reduces  development  costs,  improves  reliability,  and  increases  the 
compatibility  with  current  and  future  products.  This  feature,  along  with  items  3. 1-3.3,  indicates 
that  a good  choice  for  the  coupling  processors  would  be  an  industry  standard  32-bit  address  and 
data  bus,  such  as  Multibus-II  or  VME  bus,  configured  as  a multislot  backplane.  This  type  of 
architecture  has  been  in  use  for  many  years  and  is  well  tested. 


With  respect  to  the  distributed  part  of  the  control  system,  i.e.,  the  part  that  resides  in  the  ma- 
nipulator arms,  it  is  our  understanding  that  there  are  two  major  problems.  The  first  problem  is  ca- 


Approach  to  Computing  Arch. 


7 


bling.  It  is  desirable  to  minimize  the  number  of  cables  passing  through  a manipulator.  The  second 
problem  relates  to  themral  control  within  a manipulator.  The  amount  of  heat  generated  within  an 
arm  should  be  kept  to  a minimum.  With  these  points  in  mind,  here  are  some  features  that  may  be 
desirable  for  the  distributed  part  of  the  hardware  architecture. 

3.5.  Only  local  control  at  the  joints. 

The  nature  of  the  control  problem  for  a serial  mechanism  such  as  a robot  manipulator  requires 
a centralization  of  control  for  coordination.  An  example  of  this  is  the  inertia  decoupling  com- 
pensation required  for  FTS.  This  decoupling  can  only  be  done  for  the  manipulator  as  a whole, 
not  by  each  joint  independently.  Any  attempt  at  joint-local  decoupling  will  result  in  high  com- 
munication requirements  between  joints,  defeating  the  whole  purpose  of  the  local  joint  control. 
Thus,  it  is  important  that  any  control  distributed  to  joint  controllers  be  truly  local.  For  the  FTS 
this  means  that  only  joint  torque  control  loops  should  be  done  in  joint-mounted  electronics. 

3.6.  Digital  communication  bus  in  arm. 

The  large  number  of  sensors  (current,  temperature,  etc.)  and  the  desire  to  reduce  cabling  leads 
to  the  conclusion  that  sensory  data  should  be  digitally  encoded  and  transmitted  over  a common 
link.  A simple  hardware  link,  such  as  a twisted-shielded  pair,  may  be  best  for  this  purpose  since 
the  cable  will  need  to  be  quite  flexible  to  minimize  cable  friction.  This  need,  along  with  item 
3.4,  may  indicate  that  1553  is  an  appropriate  choice.  The  bandwidth  required  for  this  link 
should  not  be  that  great  provided  the  link  only  transmits  sensor  feedback  and  reference  signals 
for  local  control  at  the  joints.  If  additional  bandwidth  is  needed,  an  additional  digital  bus  of  the 
same  type  can  be  added  to  the  manipulator. 

3.7.  Programmable  torque  loops. 

The  widely  varying  thermal  conditions  in  which  the  FTS  will  operate,  and  the  inability  to  test 
it  fully  in  real  space  environments,  make  it  likely  that  the  torque  loop  parameters  will  need  to 
be  modified  after  the  FTS  is  constructed.  In  addition,  if  the  FTS  is  to  operate  for  a number  of 
years  on  the  space  station,  wear  and  other  aging  factors  will  also  require  that  control  parameters 
change.  Thus,  the  torque  loops  operating  on  the  joints  should  be  programmable  in  that  all  the 
control  parameters  could  be  modified.  The  most  flexible  way  to  do  this  is  to  implement  digital 
torque  loops  on  a general  microprocessor,  although  it  may  be  just  as  easy  to  implement  the 
torque  loops  using  a microcontroller  or  programmable  gain  amplifiers.  Not  using  general  mi- 
croprocessors may  be  the  better  approach  in  minimizing  size  and  heat  generated  at  the  joints. 

3.8.  Single  motor  power  bus. 

To  minimize  cabling  complexity  the  motor  power  for  the  various  joints  in  a manipulator  should 
all  be  taken  off  of  a single  power  bus.  This  implies  that  the  PWM  electronics  for  providing  mo- 
tor currents  should  be  distributed  in  the  manipulator.  The  motor  command  for  the  PWM’s  will 
be  taken  from  the  output  of  the  torque  loops. 


Considering  all  of  the  above  points,  the  telerobot  hardware  architecture  for  a manipulator/hand- 
controller  Servo  Level  pair  is  obtained  as  depicted  in  Figure  3.  (For  further  validation  of  this  basic 
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Figure  3.  Hardware  Architecture  for  Manipulator/Hand  Controller  Pair. 


approach,  consider  the  hardware  architecture  developed  independently  for  MARCS  in  Appendix 
1.)  In  this  design,  all  of  the  general  processors  reside  in  a common  backplane.  These  processors 
communicate  with  each  other  over  Multibus  II  using  common  memory  residing  on  the  shared  bus. 
The  number  of  general  386  processors  is  seven,  which  is  chosen  to  correspond  with  the  number  of 
microprocessors  used  by  Martin  Merietta  for  a manipulator/hand-controller  pair.  The  processors 
communicate  with  device-mounted  electronics  over  the  1553  serial  data  lines. 

The  device-mounted  electronics  include  all  the  electronics  necessary  to  receive  the  digital 
torque  commands  from  the  1553  and  produce  the  corresponding  actuator  motions.  In  addition, 
these  electronics  interface  the  sensors  to  the  digital  bus  for  sensor  feedback.  For  the  manipulator, 
the  device-mounted  electronics  could  be  physically  located  within  the  links  of  the  manipulator  arm. 
The  electronics  may  include,  in  addition  to  the  1553  interface,  power  electronics,  commutation 
electronics,  PWM  electronics,  torque  control  loops,  and  analog  i/o  hardware.  It  is  assumed  that 
general  microprocessors  are  not  used  in  the  device-mounted  electronics. 

Referring  back  to  Figure  2,  all  the  processes  depicted  in  the  figure  reside  on  the  seven  general- 
purpose  processors  in  the  multislot  backplane.  Thus,  the  communication  at  the  "bottom"  of  the  Ser- 
vo Levels,  (joint  torques  and  feedback  in  Figure  2,)  is  over  the  1553  bus.  By  restricting  1553  data 
to  be  this  low-level  data  only,  the  ability  of  the  1553  bus  to  meet  the  communication  requirements 
is  assured.  For  example,  if  seven  16-bit  joint  torques  are  sent,  seven  32-bit  joint  positions  and  six 
16-bit  force/torque  values  are  received,  this  requires  27  16-bit  words.  With  the  1553,  each  16-bit 
word  is  transferred  at  a cost  of  20  bits,  for  a total  of  540  bits.  Add  a few  protocol  words  and  the 
total  transfer  is  about  600  bits.  If  this  data  is  transferred  every  millisecond  then  the  required  bus 
rate  would  be  600Kbits/s.  This  rate  is  well  within  the  capabilities  of  the  1553  which  has  a specifi- 
cation for  1 Mbit/s.  If  an  actual  1553  bus  only  achieved  80%  of  this  (800Kbit/s),  the  transfer  of  600 
bits  would  still  take  only  0.75  ms. 

Now  consider  the  execution  times  presented  in  Table  1,  and  note  the  following.  Processes  4,  5, 
6,17,  and  1 8 can  run  at  a fairly  slow  rate  with  respect  to  the  rest  of  the  system  and  not  effect  control 
system  performance.  These  processes  need  not  update  their  outputs  more  than  about  20  times  a sec- 
ond. There  are  numerous  ways  to  distribute  the  remaining  processes  to  processors.  The  system  is 
completely  flexible  in  this  respect  since  all  processors  are  tightly  coupled.  Processes  can  be  distrib- 
uted to  minimize  the  around-the-loop  time  of  the  teleoperation  control,  maximize  the  processing 
margin,  minimize  the  time  between  new  updates  of  joint  torques,  or  optimize  a number  of  other 
factors. 

Suppose,  as  an  example,  a minimum  around-the-loop  time  for  the  force-feedback  teleoperation 
control  is  desired.  Note  that  the  around-the-loop  time  is  defined  by  the  process  sequence  {2,  8,  9, 
13,  14,  15,20,  19,  16,  10,  11,  12}.  By  grouping  processes  4,5,6,17,  and  18  on  one  processor,  each 
of  these  processes  would  compute  a new  output  at  around  37  Hz.  The  remaining  processes  can  be 
distributed  to  processors  as  follows. 

CPU-1  : 4,5,6,17,18 
CPU-2  : 1,2,8 
CPU-3  : 9,13,14 
CPU-4:  15,20 
CPU-5:  19,16,10,11 
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CPU-6:  12 
CPU-7:  7,3 


Here,  each  processor  executes  the  processes  in  the  order  listed.  Processors  2,  3,  4 and  6 can  each 
execute  their  processes  in  less  than  a millisecond.  The  reader  may  verify  this  by  adding  the  execu- 
tion times  from  Table  1.  Processor  5 can  execute  its  processes  in  less  than  4 ms,  while  processor  7 
takes  less  than  3 ms.  Thus,  all  the  processors  can  be  synchronized  on  a one-millisecond  boundary 
so  that  outputs  of  processes  1,  2,  8,  9,13,14,15,  20,  and  12  get  updated  every  millisecond,  outputs 
of  processes  7 and  3 get  updated  every  3 ms,  and  the  outputs  of  processes  19,  16,  10,  and  11  get 
updated  every  4 ms.  The  around-the-loop  time  is  determined  by  the  processor  sequence  {CPU-2, 
CPU-3,  CPU-4,  CPU-5,  CPU-6}.  Adding  up  the  times  for  this  sequence  (1-1-14-1-1-4+1=8),  and  mak- 
ing the  mild  assumption  that  the  additional  time-delay  for  the  1553  and  the  device-mounted  elec- 
tronics is  less  than  1 ms  per  combined  torque/feedback  transaction,  the  around-loop-time  is  10  ms. 
This  loop  has  pipelined  updates  coming  every  millisecond.  In  addition,  the  example  achieves  a 
333  Hz  local  joint  control  rate,  and  a 100  Hz  impedance  loop  rate. 

The  important  point  is  that  the  hardware  architecture  provides  many  options  in  terms  of  allo- 
cating computing  resources.  Other  processing  resource  allocations  can  easily  be  made  without 
changing  either  the  hardware  or  software  architectures.  For  example,  the  distribution 

CPU-1  : 4,5,6,17,18 
CPU-2  : 2,8,9,13,14,15,20 
CPU-3:  19,16 
CPU-4:  10,11 
CPU-5:  1,12 
CPU-6:  7,3 

with  processors  2,  3,  and  4 repeating  every  2.5  ms,  processor  5 repeating  every  1.25  ms,  and  pro- 
cessor 6 repeating  every  3.75  ms,  results  in  an  implementation  with  a 14  ms  teleoperation  around- 
the-loop  time  and  a 400  Hz  local  position  loop  on  the  manipulator.  And  this  is  with  a spare  proces- 
sor left  over.  It  is  possible  to  implement  the  whole  system  on  just  five  processors  and  still  achieve 
good  performance  by  making  the  distribution 

CPU-1  : 4,5,6,17,18 
CPU-2  : 1,2,8,9,13,14,15,20 
CPU-3:  19,16 
CPU-4:  10,11,12 
CPU-5:  7,3. 

The  examples  show  the  tradeoffs  in  performance  for  the  implementation  of  the  Martin  Marietta 
algorithm  that  can  be  made  for  the  computing  architecture  approach  of  Figures  2 and  3.  It  should 
be  noted,  however,  that  the  Martin  algorithm  has  not  been  shown  to  be  superior  in  any  way  to  other 
approaches.  In  fact,  Martin’s  use  of  explicit  inverse  kinematics  in  the  control  loop  ensures  that  the 
algorithm  can  not  be  used  for  arms  with  more  than  six  degrees  of  freedom,  or  even  with  six  degree- 
of-freedom  arms  without  simple  kinematics.  This  has  been  the  conclusion  of  both  the  NIST  and 
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Goddard  labs.  Thus,  it  is  important  that  the  control  system  design  for  a telerobot  be  able  to  run  more 
than  just  the  Martin  Marietta  algorithm.  The  system  should  be  easily  extensible  to  run  other  algo- 
rithms and  additional  levels  of  the  telerobot  functional  architecture. 

4.  Extensibility 

As  discussed  in  Section  2,  the  complete  telerobot  architecture  involves  many  more  components 
than  the  Servo  Levels  analyzed  in  Sections  2 and  3.  Some  of  these  components  are  depicted  in  the 
partial  telerobot  architecture  of  Figure  4. 

Primitive  Levels,  as  depicted  in  Figure  2,  connect  the  manipulator  and  hand-controller  Servo 
Levels  to  the  upper  levels  of  the  telerobot.  These  Prim  Levels  generate  trajectories  and  autonomous 
reference  commands  for  the  manipulator  and  hand-controller.  There  must  be  a Prim  and  an  E-move 
Level  for  autonomous  manipulator  operations  such  as  automatic  end  effector  exchange.  Thus,  the 
processes  which  realize  these  upper  levels  must  be  given  computing  resources  within  the  system. 
Note  that,  in  general,  resources  cannot  be  taken  away  from  the  Servo  Level  processes  since  many 
of  the  processes  must  remain  in  operation  when  the  upper  levels  are  active.  (The  E-move,  Prim, 
and  Servo  Levels  form  a pipeline  for  hierarchical  control.) 

With  the  hardware  design  of  Figure  3,  extra  slots  are  available  to  add  processors  for  the  upper 
levels.  Some  processors  from  the  seven  original  ones  may  also  be  available  to  implement  the  upper 
levels  depending  on  how  processes  are  allocated  to  processors  at  the  Servo  Level.  Extra  processors 


LEVEL  4 


LEVEL  3 


LEVEL  2 


LEVEL  1 


TELEROBOT 


Figure  4.  Partial  Telerobot  Control  System. 
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can  also  be  made  available  to  execute  other  subsystems  of  the  telerobot  such  as  Safety,  Positioning 
and  Perception. 

With  respect  to  Perception,  if  the  telerobot  is  to  eventually  have  the  capability  to  analyze  im- 
ages, then  it  must  be  possible  to  add  computing  resources  to  the  telerobot  to  perform  this  function. 
Generally,  specialized  hardware  is  used  to  perform  the  computationally  expensive  function  of  con- 
verting the  input  intensity  image  from  an  iconic  (spatially  based)  image  to  a symbolic  (feature 
based)  image.  Additional  general  support  computers  process  the  symbolic  image  to  complete  the 
perception  task.  A number  of  specialized  hardware  systems  exist  for  performing  image  analysis  in- 
cluding PIPE,  WARP,  PIFEX,  and  DATACUBE.  Such  specialized  hardware  should  be  easily  in- 
corporated into  the  control  system. 

With  the  hardware  design  of  Figure  3,  the  specialized  vision  hardware  can  be  given  a dedicated 
processor  in  multislot  backplane.  The  approach  which  has  been  successful  in  the  NIST  laboratory 
has  been  to  use  a PIPE  interface  board  along  with  a general  processor  to  control  and  configure  the 
PIPE.  This  allows  the  processor  to  use  the  PIPE  like  an  accelerator  to  speed  up  vision  computation. 
The  addition  of  the  PIPE  has  little  effect  on  the  performance  of  the  rest  of  the  control  system. 

5.  Conclusion 

The  design  approach  presented  here  represents  an  accumulation  of  knowledge  from  many  years 
of  work  at  NIST.  This  approach  is  well-documented  in  the  references  which  follow.  The  design 
presented  here  supports  flexibility  in  control  system  performance,  a variety  of  control  algorithms, 
and  provides  an  evolutionary  path  to  additional  telerobot  functionality. 
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Appendix  1. 


The  Multiple  Algorithm  Robot  Control  System  (MARCS)  is  currently  under  development  in  God- 
dard Space  Flight  Center’s  robotics  laboratory.  This  system  is  designed  to  run  three  different  tele- 
operation algorithms,  a Martin  Marietta-style  algorithm,  a JPL  teleoperation  algorithm,  and  an  al- 
gorithm developed  at  Goddard.  The  following  pages  are  taken  from  early  design  efforts  in  the 
project  and  are  presented  here  only  to  show  a consensus  of  viewpoint  among  two  labs  working  on 
telerobot  systems  development.  The  first  two  figures  show  the  Servo  Levels  for  the  manipulator 
subsystem  and  the  hand-controller  subsystem.  The  last  figure  shows  a preliminary  hardware  archi- 
tecture to  support  these  two  Servo  Levels. 
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